CU Amiga Super CD-ROM 6

home *** CD-ROM | disk | FTP | other *** search

/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0048.002 < prev next >

Wrap

Text File | 1990-11-06 | 20KB | 397 lines

Document: FSC-0048 Version: 002 Date: 21-Oct-90 A Proposed Type-2 Packet Extension Jan Vroonhof 2:281/1.12@fidonet Oct 21, 1990 Status of this document ======================= This FSC suggests a proposed protocol for the FidoNet(r) community, and requests discussion and suggestions for improvements. Distribution of this document is unlimited. Fido and FidoNet are registered marks of Tom Jennings and Fido Software. Purpose ======= The final goal of this document is to become a widely used standardised extension to FTS-0001, like FTS-0006, 0007 and 0008 are, and provide an elegant way to switch to a new bundling method without requiring major effort or breaking anything. Prologue ======== The main thing that needs stressing is that the additions covered by this document are FULLY (I repeat FULLY) BACKWARDS COMPATIBLE with FTS-0001 (and other existing standards and practices in FidoNet and WhatEverOtherNets that I know of). When I say "backwards compatible" I mean that problems it would create already exist in the current FTS-0001 system (e.g. zone conflicts when dealing with a non compliant system). In short it only corrects some flaws in FTS-0001 WITHOUT generating new ones. In this document I have tried to stay as much as possible on the paths of existing practices. Therefore I think implementation of the additions it proposes will not be too hard. ! Prologue to revision 2 ! ====================== ! Revision 2 of this document reserves a bit in the ! CapabilityWord for one bundle type already in use outside of ! FidoNet, RFC-822. A small change was made to the "receiving" ! flowchart in order to ensure compatibility with FSC-0039.004. ! In the process a lot of errors and omissions in the spelling, ! credits etc. were corrected. =============== ! All references in the following to FSC-0039 are to Revision 1 ! of that document. My thoughts on FSC-0039 and FTS-0001 rev 12 =========================================== First, revision 12 of FTS-0001 introduced the term "(some impls)" to indicate that some implementations used their own ! extensions to FTS-0001 (Note that in later revisions this was ! changed to "optional"). The problem is that this info cannot be relied upon, because there is no way to actually validate the data. One can only check whether the values of these fields are in the range of valid values and hope for the best. Second, FSC-0039 introduced the idea of having a bitfield (called the Capability Word) indicating whether extension data was valid. Through the Capability Word, it also made it possible to indicate the ability to support other, non type 2, packets, thus allowing for flexible migration towards type 3. It also documented the addressing extensions used by various programs. However, FSC-0039 has two flaws: 1. One cannot be sure the bitfield is zero because other implementations might use this field for their own purposes. Therefore this document includes a second validation copy for the Capability Word (CW hereafter). This copy allows the FSC-xxxx compliant software to validate the CW by comparing the two. The chance of some junk portraying itself as a CW is significantly reduced by this. ! Please note that the validation copy is byte swapped ! compared to the normal capability word. While this started ! out as a typo, I decided to leave it in as it introduces ! some extra safety, without requiring much extra code effort. ! In later revisions of FSC-0039, Mark adopted this idea of a ! validation copy too and eliminated the problem. 2. Although FSC-0039 provides a way to make packet headers 4D it is not backwards compatible. It cannot be used in FTS- 0001 sessions to unknown systems, making FidoNet still not totally 4D capable. Although it implements fields for zone and point number, an FTS-0001 compliant application is not required to look at these fields. When a point mails using these fields to implement its 4D address, a system only looking at the net/node info, as is required by FTS-0001, still sees it as a boss node, causing the obvious problems. This document provides a way for transparent point handling, using a technique already exploited by many mailers internally. It will allow this document to be implemented and used by mailers not supporting it. At the same time the danger that a point is seen as the boss node is eliminated. It does NOT provide full inter-zone backwards compatibility, but that is not needed as badly, as problems are not yet too great. Any measures to ensure backwards compatibility in this area might harm communication with non-supporting programs, when the old system could handle the situation. Packet Header ============= The "|" character is used to indicate extensions documented in FTS-0001 revision 12, the ":" character indicates those documented here and in FSC-0039. Offset dec hex .-----------------------------------------------------. 0 0 | origNode (low order) | origNode (high order) | +--------------------------+--------------------------+ 2 2 | destNode (low order) | destNode (high order) | +--------------------------+--------------------------+ 4 4 | year (low order) | year (high order) | +--------------------------+--------------------------+ 6 6 | month (low order) | month (high order) | +--------------------------+--------------------------+ 8 8 | day (low order) | day (high order) | +--------------------------+--------------------------+ 10 A | hour (low order) | hour (high order) | +--------------------------+--------------------------+ 12 C | minute (low order) | minute (high order) | +--------------------------+--------------------------+ 14 E | second (low order) | second (high order) | +--------------------------+--------------------------+ 16 10 | baud (low order) | baud (high order) | +--------------------------+--------------------------+ 18 12 | 0 | 2 | 0 | 0 | +--------------------------+--------------------------+ 20 14 | origNet (low order) | origNet (high order) | : | Set to -1 if from point | +--------------------------+--------------------------+ 22 16 | destNet (low order) | destNet (high order) | +--------------------------+--------------------------+ | 24 18 | ProductCode (low order) | Revision (major) | | +--------------------------+--------------------------+ | 26 1A | password | | | 8 bytes, null padded | | +--------------------------+--------------------------+ |: 34 22 | origZone (low order) | origZone (high order) | } | +--------------------------+--------------------------+ } As in |: 36 24 | destZone (low order) | destZone (high order) | } QMail : +--------------------------+--------------------------+ : 38 26 | AuxNet (low order) | AuxNet (high order) | : +--------------------------+--------------------------+ : 40 28 | CWvalidationCopy (high) | CWvalidationCopy (low) | : +--------------------------+--------------------------+ : 42 2A | ProductCode (high order) | Revision (minor) | : +--------------------------+--------------------------+ : 44 2C | CapabilWord (low order) | CapabilWord (high order) | : +--------------------------+--------------------------+ : 46 2E | origZone (low order) | origZone (high order) | } : +--------------------------+--------------------------+ } As in : 48 30 | destZone (low order) | destZone (high order) | } FD etc : +--------------------------+--------------------------+ : 50 32 | origPoint (low order) | origPoint (high order) | } : +--------------------------+--------------------------+ } As in : 52 34 | destPoint (low order) | destPoint (high order) | } FD etc : +--------------------------+--------------------------+ : 54 46 | Product Specific Data | : + + : | 4 Bytes | +--------------------------+--------------------------+ 58 3A | zero or more | ~ packed ~ | messages | +--------------------------+--------------------------+ | 0 | 0 | 0 | 0 | '-----------------------------------------------------' Packet = PacketHeader { PakdMessage } 00H 00H PacketHeader = origNode (* of packet, not of messages in packet *) destNode (* of packet, not of messages in packet *) year (* of packet creation, e.g. 1986 *) month (* of packet creation, 0-11 for Jan-Dec *) day (* of packet creation, 1-31 *) hour (* of packet creation, 0-23 *) minute (* of packet creation, 0-59 *) second (* of packet creation, 0-59 *) baud (* max baud rate of orig and dest *) PacketType (* old type-1 packets now obsolete *) origNet (* of packet, not of messages in packet set to -1 if orig=point *) destNet (* of packet, not of messages in packet *) + productCode Lo (* 0 for Fido, write to FTSC for others *) |+ serialNo Maj (* binary serial number (otherwise null) *) | password (* session pasword (otherwise null) *) | origZone (* zone of pkt sender (otherwise null) *) | destZone (* zone of pkt receiver (otherwise null) *) | auxNet (* contains Orignet if Origin is a point *) +! Bytesw. CWvalidationCopy (* Must be equal to CW to be valid *) + ProductCode Hi + revision Minor + origZone (* zone of pkt sender (otherwise null) *) + destZone (* zone of pkt receiver (otherwise null) *) + ProdData (* Product specific filler *) When the two copies of the CW match they can be asumed to be valid and used. Stone-Aged: Old FTS-0001 Type-2+ : Old FTS-0001 plus changes indicated by "|" and ":" are valid A Type-N Bundle will always advertise its capabilities in the CW regardless of the type being sent. As shown in the example below, the CW allows Type-N processors to automatically track the capability of your system. Again, in cases where a stone- age processor is being used, this field will be ignored, and in the unusual event that it is not ignored, and is somehow harmful to the far system, the Type-N processor can be configured to send a CW of 0. The format of the Capability Word is designed to support up to 15 future bundle types, and is bit-mapped to facilitate the easy determination of the maximum common level supported between two nodes: msb Capability Word lsb Node Supports ------------FTSC Type Supported **)------------ U 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2+ 2+,3, and 7 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 2+,3, and 5 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 2+ (this Doc) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 Stone Age 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ! ^-- "U" Indicates nodes able to process RFC-822 ! bundles. ** - In the example bit definitions only type 2, and the Stone-Age type, are defined now. The rest are to be concidered "reserved by FTSC". The receiving Type-N bundler would AND the two words, obtaining a word expressing the Types which are common to both the receiving and the sending system. The most significant Type will be used for future sessions, by default. Please note that this assumes that new bundling Types will be increasingly more efficient or in some way more beneficial. Because this may not always be the case, there should be a method provided to override the automatic upgrade, as illustrated above, should this ever happen. ! N.B. The one bit left over (Msb) is now used as indicator for ! RFC-822 type bundles. For info on RFC-822 please check out ! the relevant documents themselves. ! For a more explanatory text on using the CW to its full ! potential, refer to the FSC-0039 text by Mark Howard. ! Mark also gives some more rationale for the origional idea ! of the CW. Generating Type-2+ bundles ========================== Do we have a CW Does CW indicate stored for dest? YES ----> higher packets YES ---> Generate higher NO we support? packet | NO \|/ | +-----<----------------------+ | Fill header with all info | \|/ | Are we sending from a point? (origPoint != 0) YES --+ | | NO | | \|/ | set AuxNet = OrigNet \|/ set OrigNet = -1 | | +-----<----------------------------------------+ | Add Messages | Terminate packet | Send packet Receiving Type-2+ bundles ========================= Receive Packet | Packettype = 2 NO -------------> Process Type-Other YES | | CWcopies match NO --------+------> Treat as normal Stone-Age packet YES | | | | | Store CW /|\ | | | /|\ CW is 0 YES --------------+ | NO | | | | | CW indicates support for 2+ NO --+ YES | | ! OrigPoint is not 0 and OrigNet = -1 YES -------+ NO | | \|/ ! \|/ Set OrigNet is AuxNet | | +------<-----------------------------------+ | Process using added info Credits ======= To Mark Howard, for introducing the idea of a CW in his FSC- 0039 document and quite rightly pointing out one big omision in revision 1 of this document. To Rick Moore, for doing a good job in processing all these revisions by Mark and myself, and for his work for the FTSC in general. To Joaquim Homrighausen, for his contributions to FidoNet software in general, and especially for his time devoted to reading, discussing and implementing the ideas Mark and I introduced. To Andre van de Wijdeven, for producing and letting me beta test his TS-MM software, which in my opinion is the best point software around. (I'm not saying available, because it isn't :-() To john lots, for shipping this stuff to the US. To Jon Webb, for doing a much needed grammar and spelling check. To Bob Hartman, Vince Periello, Tom Jennings, Eelco de Graaff, aXel Horst, Arjen van Loon, jim nutt, Odinn Sorensen, David Nugent, Peter Janssens and many others, for making FidoNet what it is now, for me and for everybody. Epilog ====== So this it, now it's up to you to decide whether or not to implement it. A small change was made in the receivers flowchart and a small incompatibility with the later revisions of FSC-0039 was removed. That will ensure that FSC-0048 and FSC-0039 mailers can happily talk to each other.... The best way to implement this would be to always support FSC- 0048 on inbound trafic and generate FSC-0048 on outbound by default. A switch on a per-node basis will force your software to be FSC-0039 or even FSC-0001 only, and you will cover all bases. This can be done easily, as FSC-0048 is a superset of FSC-0039 (The -1 thing on points being the difference) which in turn is a superset of FTS-0001 (CW). I'd be glad to get some feedback. You can put it in NET_DEV or netmail me. Jan Vroonhof (2:281/1.12@fidonet)